PKI Architecture
In general, a digital certificate makes it possible to identify the holder of the certificate, i.e., the computer equipment in which the certificate is registered.
As defined by standard RFC 3280, a certificate is issued and managed by a set of hardware and software components belonging to a public key infrastructure (PKI).
A certificate includes attributes (identification of the holder, public key, validity date of the certificate, etc.), as well as a signature.
According to the asymmetrical keys technique, the public key corresponds to one and only one private key, registered on the holder's equipment.
The use of public and private cryptographic keys makes it possible, during electronic transactions, to have significant security functions, such as confidentiality, authentication, integrity and non-repudiation.
A PKI architecture includes a holder, who generates or on behalf of whom is generated, a certificate request (CSR, Certificate Signing Request), the latter including the attributes of the final certificate; a registration authority, which performs usage verifications on the values of the attributes, in particular the identity of the holder, and validates the certificate request; a certification authority, which signs the validated certificate request, so as to generate the certificate. The certificate is preferably stored by the holder.
TOIP System
A TOIP system includes IP telephones connected to an IP network, for example the local IP network of a company. Telecommunications, in particular by voice, are then conveyed through the IP network.
Advantageously, a TOIP system makes it possible to benefit from different additional services. In order to provide the services, the TOIP system includes a call server, connected to the IP network. It allows the authentication of the telephones, the transmission and reception of calls (preferably securely), call transfers, call filtering, etc. Such a call server is referred to as PABX IP or IPBX and corresponds to the evolution toward IP of a traditional PBX telephone autoswitch.
For example, the company Cisco® distributes a TOIP system including IP Cisco® telephones and a Cisco® call server, called “Cisco® Unified Communications Manager”, preferably in its current version referenced 8.6.
The Cisco® call server of the Cisco® TOIP system integrates a PKI architecture, called Cisco® PKI architecture. It includes a certifying authority, called CAPF (Certificate Authority Proxy Function) certification module. The latter is able to sign certificate requests on behalf of Cisco® IP telephones. The Cisco® certificate thus created is stored on the corresponding Cisco® IP telephone.
The Cisco® TOIP system next uses these Cisco® certificates to authenticate Cisco® IP telephones. For the authentication, the TLS (Transport Layer Security) secure protocol is implemented between a Cisco® IP telephone and the Cisco® call server. The TLS protocol was standardized by a working group of the IETF (Internet Engineering Task Force). A “handshaking” procedure is thus carried out, during which the Cisco® certificates of the Cisco® IP telephone and the Cisco® call server are exchanged, verified, and a symmetrical encryption key is negotiated to secure subsequent communications.
EAP-TSL Authentication System
Furthermore, companies implement authentication procedures in order to monitor access to their local IP network by any computer equipment.
Thus, for example, the IEEE 802.1X authentication is a standard making it possible to monitor access to the local IP network based on a digital certificate.
With the IEEE 802.1X authentication, it is possible to monitor the access to each of the ports of a compatible active network equipment item. Independently of the connection type, each port acts as a switch between two states: a controlled state in case of successful authentication of the equipment connected to this port, and an uncontrolled state otherwise.
The IEEE 802.1X authentication is based on an EAP (Extensible Authentication Protocol) protocol and on an authentication server.
As defined by standard RFC 5216, EAP designates the family of protocols, within the network meaning of the term, i.e., it provides an exchange of frames in a specific format between two pieces of equipment, one working as a server, the other as a client. It includes authentication methods that are either predefined (MD5, OTP, Generic Token Card, etc.), or added. The authentication can be requested by the client or by the server.
Among the different EAP protocols, the EAP-TLS protocol is known, which is an open standard for example relative to the EAP LEAP protocol by Cisco®, which is a proprietary implementation of the EAP protocol.
The EAP-TLS protocol is an EAP protocol that encapsulates the TLS protocol.
The EAP-TLS protocol uses the certificate issued by a PKI architecture to secure the communications between the client and the server: a server-side certificate and a client-side certificate.
It should be noted that other implementations of the EAP protocol, such as the PEAP and EAP-TTLS protocols, make it possible to eliminate this client-side certificate.
According to protocol IEEE 802.1X, the application protocol between an EAP client (computer equipment) and an EAP server (port of a machine of the network to which the computer equipment is connected) is as follows:                the EAP client sends an EAP initialization message to the EAP server;        the EAP server responds by sending an EAP identity request message to the EAP client;        the EAP client sends its username in a response EAP message to the EAP server;        the EAP server sends the username to an AAA authentication server, in an access request according to a particular AAA client/server protocol, the EAP server then working as client of the AAA protocol;        the AAA application server responds to the EAP client by sending it (via the EAP server) the certificate of the AAA server;        the EAP client validates the AAA server certificate;        the EP client responds to the AAA server by sending it (via the EAP server) the certificate of the EAP client;        the AAA server validates the certificate of the EAP client;        the EAP client and the AAA server determine a WEP encryption key;        the AAA server sends the EAP server an AAA acceptance message of the connection, indicating a successful authentication, the AAA acceptance message containing the WEP key;        the EAP server sends the EAP client an EAP success message;        the EAP server sends the EAP client a public encryption key and a public encryption key length, encrypted with the WEP key.        
Appendix D of the reference document for the IEEE 802.1X authentication mentions, as an example of AAA protocol and authentication server, only the RADIUS (Remote Authentication Dial-In User Service) protocol and authentication server. The RADIUS system is defined by standard RFC 2865.
Thus, although the IEEE 802.1X authentication is not explicitly connected to the RADIUS system, all known implementations of the IEEE 802.1X authentication are based on the RADIUS system. The RADIUS system has thus become a de facto standard.
It should be noted that the RADIUS client, i.e., the EAP server, is responsible for requesting the username and certificate of the equipment trying to connect to the monitored port and sends them to the RADIUS server.
The RADIUS system bases its authentication on the username of the equipment and, in the case of EAP-TLS application, the certificate of the equipment.
Among the hardware and software suppliers, the NPS (Network Policy Server) system by Microsoft®, integrating a RADIUS server, or NPS RADIUS server, is already widely deployed in companies to authenticate equipment: employees' personal computers, routers on the local network, gateways between sub-networks or toward the outside world, etc.
The NPS system includes a directory database. However, the NPS system is preferably associated with the Microsoft® Active Directory server. The latter stores the accounts of network users and a match table between usernames and the signature of the user's certificate. A signature of a certificate is calculated from the values of certain identification attributes of the user that are present in the user's certificate.
Thus, the step during which the AAA server validates the certificate of the EAP client takes place as follows, for the case of an NPS system coupled to a Active Directory server: the NPS RADIUS server receives the username and the certificate of the EAP client. The NPS RADIUS server queries the Active Directory server to determine whether the username is associated with a user account. If it is, the NPS RADIUS server sends certain attributes of the certificate of the EAP client to the Active Directory server, which compares the values of these attributes with the imprint associated with the username in the match table. If there is a match, the Active Directory server indicates to the RADIUS server that the client can use the network. The RADIUS server continues by verifying, using appropriate rules, other attributes of the certificate: verification of the validity date, verification of the accreditation of the certifying authority having signed the certificate, etc. If the outcome of these various verifications is positive, the NPS RADIUS server validates the certificate of the EAP client. The rest of the authentication protocol can then take place.
In order to connect IP telephones to the company's local network, it is desirable to be able to authenticate this IP telephone like any other piece of equipment of the network.
The Cisco® manufacturer provides a complete infrastructure associating, in its TOIP Cisco® system, a call server and a PKI architecture.
However, this Cisco® TOIP system is proprietary. As such, this poses a security problem for companies that wish to achieve a high level of security of their facilities. Indeed, the certifying authority for Cisco® IP telephone certificates is a default authority, shared by all implantations of the Cisco® TOIP system.
Furthermore, many companies are already equipped with the Microsoft® NPS authentication system. If a company wishes to deploy IP telephones, in particular Cisco® IP telephones, it is necessary to manage an authentication system specific to Cisco® IP telephones, redundantly with authentication servers already installed for the other equipment on the network. This represents an excess cost in terms of hardware, maintenance and training of maintenance staff for such a proprietary infrastructure.
There is therefore a need to be able to authenticate an IP telephone of a proprietary TOIP system, developed by a first supplier (in particular the Cisco® TOIP system), using an open EAP-TLS authentication system, developed by a second supplier (in particular the Microsoft® NPS authentication system), while using a PKI architecture external to the TOIP system, so as to increase security on the IP network.